REMARKS 

Claims 1-33 are pending. Claims 1, 24, and 33 are amended. Claims 34 and 35 are new. 
The amendments and new claims are supported in the application as filed, for example at 
paragraphs [0033]-[0035] and [0043] -[0048]. No new matter was added. 

Applicant's Attorney thanks the Examiner for discussing the application in a telephone 
interview on December 8, 2009. In the interview, proposed claim amendments further 
distinguishing the cited reference were discussed. The professional manner in which the 
interview was conducted significantly advanced prosecution. 

Rejection under 35 U.S.C. § 102 

Claims 1-33 were rejected under 35 U.S.C. § 102(e) as anticipated by Flaxer et al., U.S. 
Patent Pub. No. 2004/0162741 (hereinafter "Flaxer"). It is respectfully submitted that claims 1- 
33 are not anticipated by Flaxer for at least the following reasons. 

Flaxer relates generally to techniques for providing access to services on a network, 
called the PLM-web. (Abstract). "PLM-web is a distributed interconnection of process flow 
managers (supervisors of dynamic workflow processes) and service providers that subscribe to 
an implementation of unique service ontology models, service composition schema models, and 
event messages models." (<][ [0022]). A business process proxy, which encapsulates for public 
access the internal processes of the service provider, is provided by the service provider for each 
service description. (Abstract). Each business process also has a business flow manager that 
dynamically composes ad-hoc workflow prior to the execution of the business process. 
(Abstract). 

The business process proxy described in Flaxer is a service adapter created by the service 
provider that maps the internal processes of the service provider to the public processes known to 
the PLM-web. [0312]). These public processes are published by the service provider into the 
PLM repository. (^ [0313]). Thus, users may access the services provided by the service 
provider by making use of the public processes provided in the public interface, which are 
mapped by the business process proxy to the service provider's internal, private processes. 
[0312]). 

The business process proxy also includes a workflow manager and service process 
manager. [0314]-[0315]). The service process manager "is responsible for the overall 
coordination of business proxy tasks. It provides a mechanism to map the private service 
provider processes 2010 to a publicly defined workflow 2022 that is subsequently published and 
maintained in the PLM repository 1840." [0314]). According to Flaxer, "the workflow 
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manager 1910 maintains the tracking of tasks and state transitions associated with the microflow 
(provider workflow). As changes occur within a workflow instance the workflow manager 1910 
initiates message events broadcast to the PLM-flow managers 1810 advising them of these 
conditions." (f [0315]). 

In contrast to the teachings of Flaxer, the claims of the present application recite 
techniques for enabling consumption of services via a services network by providing different 
connectors for a service that reflect the protocols and policies of different consumers of that 
service. Users in communication with the services network are provided with access to a 
services directory that identifies one or more connectors for each of the services. Each connector 
is operable to facilitate consumption of the corresponding service and to mediate communication 
protocol and business policy differences between a first end point on the network associated with 
the corresponding service and one or more end points on the network associated with the 
corresponding enterprise. At least some of the services have two or more different connectors 
configured to facilitate consumption of the services by consumers associated with different ones 
of the enterprises. 

Further, selected ones of the users are provided with access to connector design process 
represented by a graphical user interface operable to facilitate creation of a new connector. A 
first communication protocol by which one or more consumers associated with the enterprises 
corresponding to the selected users may communicate with the new connector may be specified 
via the connector design process. The new connector is operable to translate communications 
between the first communication protocol and a second communication protocol associated with 
the corresponding service. 

The Office Action seems to suggest that the business process proxy described in Flaxer is 
analogous to the connectors recited in the claims. However, each service in Flaxer has only a 
single business process proxy. A service provider's business process proxy provides a mapping 
between public processes that a service provider wishes to make available to users on the PLM- 
web and the service provider's internal, private processes, (f [0312]-[0313]). "This concept is 
illustrated in FIG. 20, where the private processes 2010 (comprised of private workflow 2012 
and private controls 2014) and private data 2016 and private interfaces 2018 are hidden from the 
PLM-web 2030 through the use of the business process proxy 2020." [0312]). Figure 20 of 
Flaxer is reproduced below: 
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By its very definition, Flaxer's business process proxy reflects the characteristics of only 
a single end point on the network, i.e., the service provider with which it is associated, and 
therefore cannot reflect the communication protocol and business policies of different consumers 
of the service. Instead, consumers of the service must conform to the service provider's public 
interface presented by Flaxer's business process proxy. Thus, Flaxer achieves the very opposite 
of consumer end point customization. In contrast to Flaxer, the claims recite different connectors 
that are each operable to mediate differences in communication protocols or business policy 
differences between the service provider and one or more different users of the service, i.e., 
consumer end point customization. Thus, in contrast to the teachings of Flaxer, the claims recite 
different consumers of a service communicating with the service via different connectors that are 
customized according to the communication protocols and business policies (such as 
authentication protocols or legal restrictions on the use of a service) of the corresponding 
consumers. Because Flaxer's business process reflects only the characteristics of the service 
provider, Flaxer fails to disclose or suggest the different customized connectors recited in the 
claims. 

In addition, nowhere does Flaxer describe any design process for new connectors for a 
service. Instead, as discussed above, a single business process proxy is established by the service 
provider. (<([ [0312]). For example, Flaxer states "Once the business process proxy is established 
the service provider publishes their public process, based on service ontology and service 
composition schema, into the PLM repository that enables identification and service composition 
integration into the PLM workflow." [0313]). By contrast, the connector design tool recited 
in claim facilitates the creation of a new connector for the corresponding service, and allows a 
consumer of that service to specify at least one business process for mediating the business 
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policy differences. Furthermore, the new connector is operable to translate communications 
between a first communication protocol by which one or more users may communicate with the 
new connector and a second communication protocol associated with the corresponding service. 

Nowhere does Flaxer disclose or suggest such a connector design tool, much less a 
connector design tool represented by a graphical user interface. In fact, because Flaxer' s 
business process proxy is intended to provide a single public interface by which the 
corresponding service may be consumed, there is no need in Flaxer' s approach for such a design 
process. Instead, as mentioned above, consumers of services must conform to the interface made 
public by the business process proxy. Thus, the business process proxy is fundamentally 
different than the connectors and connector design process recited in the claims. 

The business process proxy described in Flaxer includes a service process manager and 
workflow manager, [0314]). However, because these components are part of the business 
proxy, they are fundamentally different from the connector recited in the claims for at least the 
reasons discussed above. Flaxer does describe these components as capable of resolving 
conflicts among rules. (<([ [0259], [0290]). However, the business rules described in Flaxer relate 
to business process flows running on the PLM-network. (^[ [0153]). Nowhere does Flaxer 
disclose or suggest that these rules include, for example, communication protocols used by a 
consumer of a network service, as recited in the claims. Furthermore, Flaxer states that resolving 
these rules conflicts involves either "allowing the user to modify the rules or change the input 
data" or finding "another PLM-flow schema that can avoid the conflict." (f [0290]). Thus, 
Flaxer suggests that differences in rules require modification of the rules or using a different 
process. By contrast, the claims recite a connector design process for designing new connectors 
to reflect the communication protocols and business policies of consumers of the service so as to 
mediate differences between the service and one or more consumers of the service. 

Furthermore, Flaxer fails to disclose or suggest any design process for the service process 
manager and workflow manager. Instead, Flaxer states that "end users only need to specify the 
service schema of the target task 810 (that represents the end objective of the business process) 
and provide necessary input data 820" (^[ [0153]). The PLM-network then creates a PLM-flow 
based on the defined end objective. [0153]). Thus, the user does not seem to communicate 
directly with a specific service in Flaxer' s system. Instead, the PLM-network "dynamically adds 
tasks" and selects appropriate services and schemas. (<][ [0153], [0290]). Therefore, under 
Flaxer' s system, a network user is not provided with any connector design process operable to 
facilitate creation of a new connector for a specific service, as recited in the claims. 
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Since Flaxer does not describe two or more different connectors for the same service, 
connectors customized according to the business policies and business policies of different 
consumers of the service, and a connector design process for creating new connectors as recited 
in the claims of the present application, it cannot be said to anticipate or obviate the claimed 
invention. That is, Flaxer does not teach or suggest a connector that is operable to mediate 
communication protocol and business policy differences between the corresponding service and 
the consumer of the service, or any connector design process that facilitates the creation of new 
connectors. Therefore, the rejection of the all of the claims of the present application over Flaxer 
should be withdrawn. 

In view of the foregoing, Applicants believe all claims now pending in this application 
are in condition for allowance. The issuance of a formal Notice of Allowance at an early date is 
respectfully requested. If the Examiner believes a telephone conference would expedite 
prosecution of this application, please telephone the undersigned at (510) 663-1100. 

Respectfully submitted, 

WEAVER AUSTIN VILLENEUVE & SAMPSON LLP 

/Joseph M. Villeneuve/ 

Joseph M. Villeneuve 
Reg. No. 37,460 

P.O. Box 70250 

Oakland, California 94612-0250 
(510) 663-1100 
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